1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer program product for exchanging supplemental information fields between a client and a server using existing communications protocols.
2. Description of the Related Art
It is commonplace today for computer users to connect their machines to other computers, known as xe2x80x9cservers,xe2x80x9d through a network. The network may be a private network, such as a corporate intranet of networked computers that is accessible only to computer users within that corporation, or it may be a virtual private network such as an extranet of computers that is accessible only to computer users having well-established access rights, or it may be a public network, such as the Internet or World-Wide Web. The Internet is a vast collection of computing resources, interconnected as a network, from sites around the world. The World-Wide Web (referred to herein as the xe2x80x9cWebxe2x80x9d) is that portion of the Internet which uses the HyperText Transfer Protocol (xe2x80x9cHTTPxe2x80x9d) as a protocol for exchanging messages. Alternatively, other protocols such as the Wireless Session Protocol (xe2x80x9cWSPxe2x80x9d) can be used, where this protocol is used for wireless communications.
The user working in a networked environment will have software running on his workstation to allow him to create and send requests for information to a server and to receive and view the results. When the user connects to the Web, these functions are typically combined in software that is referred to as a xe2x80x9cWeb browser,xe2x80x9d or xe2x80x9cbrowser.xe2x80x9d After the user has created his request using the browser, the request message is sent out into the Internet for processing. The target of the request message is one of the interconnected servers in the Internet network. That server will receive the message, attempt to find the data satisfying the user""s request, format that data for display with the user""s browser, and return the formatted response to the browser software running on the user""s workstation. The response is typically in the form of a displayable file, referred to as a xe2x80x9cWeb page,xe2x80x9d that may contain text, graphics, images, sound, video, etc.
These are examples of a client-server model of computing, where the machine at which the user requests information is referred to as the client, and the computer that locates the information and returns it to the client is the server. In the Web environment, the server is referred to as a xe2x80x9cWeb server.xe2x80x9d The user may connect his computer to a server using a xe2x80x9cwirelinexe2x80x9d connection or a xe2x80x9cwirelessxe2x80x9d connection. Wireline connections are those that use physical media such as cables and telephone lines. Wireless connections, on the other hand, use media such as satellite links, radio frequency waves, and infrared waves. The user""s computer may be any type of computer processor, including laptops, hand held or mobile computers; vehicle-mounted devices; cellular telephones and desktop screen phones; pagers; desktop computers; mainframe computers; etc., having processing and communication capabilities. The remote server, similarly, can be one of any number of different types of computer which have processing and communication capabilities. A wide variety of server computer capabilities exist including high speed, multiprocessors with extensive real and virtual memory. These concepts are well known in the art, and the hardware devices and software which enable use of these techniques are readily available. Hereinafter, the user""s computer will be referred to as a xe2x80x9cclient device,xe2x80x9d and use of the terms xe2x80x9cclient devicexe2x80x9d or xe2x80x9cserverxe2x80x9d refers to any of the types of computing devices described above.
HTTP, the most widely used communication protocol on the Internet, provides communication capabilities that are basic by design. The HTTP protocol was designed using a simple request-response model where a client issues a request for information, and a server gathers the requested information and sends it back to the requesting client. On the other hand, WSP is emerging as the prevalent communication protocol used for wireless Internet access. WSP is modeled on the HTTP protocol and includes the HTTP functionality, but it is optimized for the wireless environment. (Hereinafter, discussions with reference to HTTP are intended to include WSP unless specifically stated otherwise.) With the skyrocketing growth of the Internetxe2x80x94both in the number of users accessing the Internet, as well as the amount of data transmitted through the Internetxe2x80x94it is advantageous to optimize the interactions between the client and server wherever possible, as well as to provide mechanisms for controlling access to content.
One type of optimization is to have the server provide a customized response to the client (such as not sending data that this client cannot use). The types of information that the server may use in providing customized information depend on the server application. For example, it may be advantageous for the server to know the physical characteristics of the client device. These characteristics may include the size of the client""s display, the amount of disk space, and/or the amount of memory on the client device. After acquiring this information from the client, the server can adapt the response based on the size, type, format, or other capabilities/restrictions of the requesting client device, thereby generating a customized response. In the case of a small, handheld device, for example, the server may remove all graphic images from the response if the handheld device is not able to display graphic images. As new types of devices enter the marketplace, the server can be easily adapted to handle the new device characteristics. For example, a small device that has no keyboard but accepts commands from voice input and responds using voice output would likely not be capable of handling any images. The server would preferably customize the response to this device by removing images and responding with text to the client. Or, the server might respond by processing the text file itself using a voice synthesizer, and by sending a media file of the synthesized text for the client device to play.
One type of access control mechanism that may be provided is for the server application to request information prior to even determining whether to respond to the client request. Types of information which the server application may wish to obtain from the client for use in controlling access to content include security-related data (such as session keys, a user""s identification, etc.), as well as device characteristics (as described above).
Hereinafter the phrase xe2x80x9csupplemental informationxe2x80x9d will be used to refer to any information which a server may find useful in processing a request from a client.
A challenge in processing client requests is that the information requests are dynamic and typically unpredictable in nature. The server application cannot expect all initial client requests to include the full set of information needed to adequately service the request and/or customize the response. If the server requires additional information which was not included in the initial request from the client, then the server needs to request the additional supplemental information from the client.
There are a vast number of clients and servers in use today, operating according to existing communications protocols. Techniques for exchanging supplemental information between the server and client exist today. A number of problems are associated with these existing approaches, however.
One approach sends one or more error codes from the server to indicate to a client that a supplemental data field must be supplied by the client before the server can respond. These error codes, however, are existing features of the protocol which are then overloaded with new semantics for the supplemental data exchange. The obvious problem with this approach is that clients that do not know about the new and special semantics of one of these error codes cannot complete the protocol. This can be desirable in some cases, for example when content must not be delivered if the client cannot provide a supplemental data item (such as an encryption key). In many cases, however, the supplemental data item is optional, and intended to help customize the content at the source. In these cases, this method will needlessly terminate with the error code. Another problem with this error code approach is that intermediate gateways or proxies may attempt to interpret or augment error codes in the server replies, for example by attempting to retrieve the same content from a mirror site, cache, or by forwarding yet another error code (supplying additional error information, for example) to the client.
Another existing approach uses new primitives to request the supplemental information. These new primitives, however, will not be understood (and therefore cannot be processed) by existing clients, again causing termination of the client request without receiving the requested supplemental data. Yet another approach uses a support layer residing under the existing client software, where the support layer implements new protocol extensions for requesting supplemental information. This support layer, which is typically implemented as an application-level proxy, intercepts the protocol extensions, thereby isolating the client""s existing software. The layered approach may translate the extensions into primitives that the existing client software can understand, or it may trap the extension for its own local use without forwarding the message on to the client. This approach, however, is problematic in that some of the content sent to a client may use sequence numbers in each response (e.g. for cookie management or other security-related features). The support layer is likely to disrupt the monotonic property of the sequence numbers. Moreover, the support layer must perform data reception, processing, and transmission tasks that slow the content retrieval. Finally, this support layer, being separate from the original browser, creates a maintenance burden on the user who must manage and debug the complex software configuration.
Unfortunately, there is no standard method for the server to verify whether a client is a xe2x80x9cstandard clientxe2x80x9d or an xe2x80x9cextended clientxe2x80x9d (i.e. one which understands overloaded error codes, protocol extensions, etc.), in particular once the request is delivered through a complex delivery chain via proxies and possibly transcoders. Thus, the server cannot a priori determine whether to use HTTP in its standard form or with one or more extensions. It is therefore advantageous for any approach which gathers supplemental information through interactions between the client and server to maintain the functionality of the existing communications protocol. This backward compatibility allows the current client software to continue operating while newer versions of client software can recognize and respond to any new protocol functions or extensions.
Accordingly, a need exists for a technique that enables a server to request supplemental information from a client while avoiding the problems which have been discussed for existing approaches. This technique must function within the existing client-server protocol, allowing older versions of the client browser software to operate unchanged while enabling newer versions to recognize and respond to the server""s information request.
An object of the present invention is to provide a technique for enabling a server to request and obtain supplemental information that is not provided in a client""s original request.
Another object of the present invention is to provide a technique for enabling a server to provide customized responses to client requests.
Yet another object of the present invention is to provide this technique using existing communications protocols, thereby enabling older client software to continue functioning without changes while enabling newer versions to exploit the technique.
Still yet another object of the present invention is to provide this technique such that a client that does not understand the request for supplemental information does not prematurely terminate the communications.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a system, method, and computer program product for use in a computing environment having a connection to a network, for exchanging one or more supplemental information fields between a client and a server. This technique comprises: receiving a client request for a Uniform Resource Locator (URL); determining whether the server can complete the client request; sending a completed response to the client request when the determining has a positive result, wherein the completed response may reflect any available ones of the one or more supplemental information fields; and performing further processing of the client request when the determining has a negative result. This further processing comprises: sending a first REDIRECT message to the client if the client request cannot be completed by the server but can be completed by a different server, wherein the first REDIRECT message specifies a different URL associated with the different server; sending a supplemental information request to the client when any of the one or more supplemental information fields are required before completing the client request; and sending an error message to the client when (1) a predetermined number of attempts by the client to supply the required supplemental information fields have been unsuccessful or (2) the one or more supplemental information fields are not required to complete the client request and the client request cannot be completed by the different server.
Preferably, the sending of a supplemental information request uses a second REDIRECT message which includes a list of the required supplemental information fields encoded in a request header. The second REDIRECT message may use a page permanently moved status code, or a page temporarily moved status code. The second REDIRECT message may use a Hypertext Transfer Protocol, or a Wireless Session Protocol. The second REDIRECT message may specify a target URL which is located on this server, or which is not located on this server.
Optionally, this technique may operate on a proxy server.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.